Eager in/clone_in - #9277

The old two-phase wrapper model recorded wrappers in a map and applied
them during lowering (WrapCalls). Because resolution read the pre-rewrite
graph while the rewrite was deferred, the literal and effective graphs
diverged, which was the common cause of several bugs:

 - Issue 3661: cloning the same Func twice crashed, because deep-copying a
   Func that already carried wrappers couldn't remap them.
 - "Deletion via cloning": a clone_in that redirected the only path to an
   already-wrapped Func orphaned it, leaving it in the environment but dead
   in the effective graph, tripping an assert in RealizationOrder.

Custom in(g)/clone_in now rewrite the named consumers eagerly, so the graph
always reflects reality and both bugs become unreachable. The consumer is
frozen afterwards, since a later definition wouldn't be wrapped.

Global f.in() is expressed as a global_wrapper link on the Func plus a
follow flag on call-node FunctionPtrs: get() follows the link, so a call
resolves to the wrapper as if every caller had been rewritten, and the
deep_copy that lowering already does materializes it (rebuilding each call
with the wrapper's name). Self-references and wrapper bodies are marked not
to follow (via WeakenFunctionPtrs) so they don't cycle. This is retroactive,
future-capturing, and chains (f.in().in()) for free, and removes the need
for the deferred WrapCalls pass, which is deleted.

Adds a fuzz test combining in/clone_in into deep chains and indirect wraps,
an error test for adding a definition after wrapping, and a func_clone
regression test. Reorders two update-after-wrap tests to define-then-wrap.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

The follow_global_wrappers flag is what makes a call node resolve to a
Func's global wrapper (Func::in()). It was set only at the user-facing
FuncRef chokepoints, so two consumer edges escaped it:

- Autodiff builds its adjoint calls directly via Call::make, so a global
  wrapper never redirected them. The wrapper ended up with no consumers
  and was pruned, making a compute_at onto it an invalid location (seen
  in the anderson2021 cost-model schedule).

- Pipeline::get_func returned a handle built from a Call node, inheriting
  its follow flag. After a first Func::in() the handle shifted to the new
  wrapper, so a second Func::in() wrapped the wrapper.

Drop the default on Call::make's follow_global_wrappers argument so every
consumer-edge site states intent, set it true in autodiff, and have
get_func return a non-following handle. The rfactor self-reference and the
ScheduleFunctions blend self-call stay non-following.

Add tests: an rfactor+in test whose call graph pins the external edge
(follows) versus the intermediate's self-reference (does not), and a test
that Func::in() on a get_func handle is idempotent.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>